-
Notifications
You must be signed in to change notification settings - Fork 614
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Create time syncronization protocol #7007
base: main
Are you sure you want to change the base?
Conversation
[[format]] | ||
=== Message Format | ||
|
||
TODO: Should I have an arbitrary magic value? do i need checksums? should we include a sequence number or other way to check if a message was replied to besides checking if we got the timestamp we expected back? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The client can treat the client timestamp as a sequence number if it's monotonic
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Implemented using this, and having the client throw out all pongs that don't match the currently active ping. This does mean that if you send pings faster than the server can handle, you might just never get your reply back since it'll get swapped out, which isn't great.
We need to be careful about using kernel timestamping- it uses the system clock, which can jump forward and backwards if the time is adjusted (e.g. on initial DS connection) |
Yeah, it might be best to drop that feature for now. |
Co-authored-by: Jade <[email protected]>
Co-authored-by: Joseph Eng <[email protected]>
8c13a38
to
3d870ab
Compare
A very rough first pass at splitting the time sync requirements out into their own UDP thing. Putting this up early with a bunch of todos for visibility and to solicit feedback